oof. Very hacky. I'd prefer to just keep the status quo. It's not that bad and we can use it to prioritize the rustdoc issues more

I would be grateful if you could expedite some fixes in rustdoc, but in my opinion having a workaround in place until rustdoc gets fixed is less bad than having the documentation remain in the current state for the same duration.

The workaround can be removed as soon as the version of nightly rustdoc used by docs.rs no longer produces less legible / less copy-pasteable documentation without it.

Beyond the associated type issue from the screenshots which is my prevailing concern, here are some other issues you could help with, which I have noticed in the serde documentation with re-exports:

• rustdoc [src] link for modules goes to mod x; when the module is re-exported across crates rust-lang/rust#49339
  The "Source" links at the module level, for example in serde::de

• Rustdoc ignores no_inline when re-exporting modules from other crates rust-lang/rust#131180
  Affects serde::ser::StdError and serde::de::StdError

• Re-exported types have confusingly different documentation rust-lang/rust#44306
  The spelling of Self in signatures such as serde::de::value::MapDeserializer::new

• The use of core::fmt::Result vs core::result::Result<(), core::fmt::Error> in the documentation of impl<'a> Serializer for &mut Formatter<'a>
  • Something else I noticed in this impl, the associated type problem means rustdoc is producing signatures that wouldn't even compile. -> Result<<&mut Formatter<'a> as Serializer>::SerializeSeq, Error>

    error[E0106]: missing lifetime specifier
       --> serde_core/src/ser/fmt.rs:117:60
        |
    117 |     fn serialize_seq(self, _len: Option<usize>) -> Result<<&mut Formatter<'a> as Serializer>::SerializeSeq, fmt::Error> {
        |                                                            ^ expected named lifetime parameter
        |
        = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from

Some other things that are solved by the workaround in this PR, which are not going to be solved in rustdoc and we will need some other workaround (probably easy) if not using this one:

• Tuple impls, which are rendered impl<'de, T> Deserialize<'de> for (T₁, T₂, …, Tₙ) in serde_core but not serde

• doc(cfg), such as on serde_core::de::Visitor::visit_string, is missing in serde